Fixes #752. This is a case of us not providing just not quite enough
information to the compiler, along with the compiler itself being too
clever. The default for `CSV.Rows` is to treat each column as
`Union{String, Missing}`, which results in the `V` type parameter of
`CSV.Rows` being `CSV.PosLen`, instead of `Any`. If that's the case, we
should get pretty good inferrability for `getproperty(::Row2,
::Symbol)`, because we should be able to know the return value will at
least be `Union{String, Missing}`. This knowledge, however, was trapped
in the "csv domain" and not expressed clearly enough to the compiler. It
inspected `Tables.getcolumn(::Row2, nm::Symbol)` and saw that it called
`Tables.getcolumn(::Row2, i::Int)`, which in turn called
`Tables.getcolumn(::Row2, T, i, nm)`. This is all fine an expected,
except that when we started supporting non-String types for `CSV.Rows`
(i.e. you can pass in whatever type you want and we'll parse it directly
from the file for each row), we added an additional typed
`Tables.getcolumn` method that handled all the non-String columns. Oops.
Now the compiler is confused because from `Tables.getcolumn(::Row2,
nm::Symbol)` it knows that it can return `missing`, a `String`, or if we
call this third method, it'll return an instance of our `V` type
parameter, which, if you'll remember, in the default case is
`CSV.PosLen`, or more simply, `UInt64`. So we ended up with a return
type of `Union{Missing, UInt64, String}`, which makes downstream
operations even trickier to figure out.

Luckily, the solution here is to just help connect the dots for the
compiler: i.e. define specialize methods that dispatch on `V`,
specifically when `V === UInt64`. Then the compiler will see/know that
we will only ever call the `Union{String, Missing}` method and can
ignore the custom types codepath. This PR also rearranges a few
`@inbounds` uses since we can avoid the bounds checks further down the
stack once we've checked them higher up.